Special Considerations

Object naming considerations

If your project includes other libraries that contain objects with names identical to those found in the Crystal Report Engine Object Library, you will encounter conflicts unless you reference the objects using a prefix that identifies their source. For example, if you have included the DAO Library with the RDC runtime object library in your project, you will find that both libraries include a Database Object. In order to avoid conflicts, you must prefix the objects as follows:

CRAXDRT.Database

for the object from the RDC runtime Object Library, or

DAO.Database

for the object from the DAO Library.

Scope considerations

When you specify a data source using code, it is important you place the code in the appropriate location in your project.Otherwise, you will face "no data" or runtime error situations because the report may be searching for data that has gone out of scope.

By default, the program does not read data into the report until you actually run the report (print it, preview it, etc.). Anything that terminates the connection to the data source before this time will cause out of scope problems.

Typical out-of-scope problems include:

Both problems can be corrected by declaring the variable for the recordset at the module level.

Dim CRXReport As New CrystalReport1
Private Sub Form1_Load()
Call SetData
     CRViewer1.ReportSource = CRXReport
     CRViewer1.ViewReport
    End Sub Private Sub SetData()
Dim rs As New ADOR.Recordset
     rs.Open "Select * From Customer", "Xtreme Sample Database"
     CRXReport.Database.SetDataSource rs, 3, 1
    End Sub

In this example, although the CRXReport object is global (for the Form), the rs object exists only for the life of the SetData procedure. Even though it is assigned to the Report object before SetData finishes, the object, and the data that rs represents goes out of scope and is invalid for the Load event. Thus, the code will fail.

This problem can be solved using the ReadRecords method. ReadRecords forces the report to read the records into the report so that they are internal to the Report object itself rather than remaining as a separate Recordset object referenced by the report.

Private Sub SetData()
Dim rs As New ADOR.Recordset
     rs.Open "Select * From Customer", "Xtreme Sample Database"
     CRXReport.Database.SetDataSource rs, 3, 1
     CRXReport.ReadRecords
    End Sub

In this case, the records are read into the report prior to the end of the procedure. Thus, when the procedure ends, the recordset object may be discarded but the records are still available for use.

Index considerations

The various collections in the RDC object model are all one-based, that is, the first member of a collection has index number 1, the second member has index number 2, and so forth. Collection members are indexed consecutively in the order that they are created.

Dual Interface considerations

The Report Design Component provides dual interfaces. As a result, development environments such as Visual Basic and Visual C++ can bind with vTable interfaces at compile time, and less robust environments, VBA, ASP, for example, can use the IDispatch interface for runtime-only binding.

It is important that you use the more efficient vTable interface if it is supported by your development environment.

When you work with Visual Basic, always use the more efficient vTable interface as long as you Dim your object variables using specific class names instead of using the more generic "Object" type.



Seagate Software IMG Holdings, Inc.
http://www.seagatesoftware.com
Support services:
http://support.seagatesoftware.com